The Constrained Application Protocol (CoAP) is a web transfer protocol targeted for constrained connected devices and networks. Such devices may need to be involved in multiple transactions, for which a certain order of processing/execution is needed. One example is:
1) A node requests a sensor reading from a machine device (MD)
2) Based on received information about the reading, the node transmits a sensor configuration to the MD, e.g. to specify which measurement configuration is to be used for the next (or a particular type of) sensor reading. Possibly this step includes also another action (e.g. heat up probe X, add water).
3) The node requests a new sensor reading from the MD according to the new configuration (and after the actions).
The sequence of the execution is determined by the order of how CoAP transactions are communicated and making transactions sequential. So first transaction 1) in the above example is transmitted. Only after the response to the first transaction has been received by the node (i.e. when the transaction is finished) the next transaction 2) is initiated and so forth.
The CoAP protocol supports acknowledged transactions that can be used to confirm that a transaction was successfully received and acted upon in order to achieve proper ordering of actions, as shown in FIG. 1 where a transmitted first Action is followed by an acknowledgement before the second Action is transmitted etc.
In many use cases, MDs are running on short-range radio technologies and have battery-saving sleep modes so the MD itself or other nodes on the transmission paths are sleeping during certain times. In this case transaction messages are either buffered in the network until the end of the sleep period, or they are retransmitted after a timeout. For sleepy devices, sequential communication of multiple transactions, where one waits for the acknowledgement of the previous transaction before sending the next one, can take long time and are often not efficient, since data cannot be transmitted entirely when a device wakes up, but it is sent in multiple occasions spread in time.
The basic acknowledgement solution shown in FIG. 1 requires waiting for an acknowledgement message before the next action can be sent. If the network has long round-trip times (e.g. due to nodes on the transmission path sleeping and hence requiring storing the message in the network while waiting for the nodes to wake up), this will result in a long delay before all transactions are completed, and/or requires nodes to stay awake for a longer time in order to transmit all messages of a sequence.